This is the Streamerp2p v2.06 broadcasting client.

Here are some incomplete instructions.

Click the antenna icon to show the broadcasting setup tabs. Broadcasting using v2.00 is almost the same as in 1.47, but things have been moved around.



Logos/Icons
-----------

Each station has a small icon that appears in the stations list, and also a larger banner that shows in the top panel of the player when tuned to that station. Put your station image files in folder 'metadata'. 
icon.jpg/gif  max 24k,  48x36. The list icon.
logo.jpg/gif  max 200k, 1000x90. The banner. It centres itself, and the middle 376 pixels is what fits ino the minimum size.
There is also an optional file 'logo.txt' that controls the colours of the logo and top area text. It contains a colour modifier string for the logo, the background/fill colour for the top panel, and the text colour for the top panel. If it is missing the broadcaster guesses sensible colours to used based on the image. Or maybe you just get black.


Player skinning
---------------

Each station can define a skin for the player which the player will used when tuned to that station. These skin definitions can also be used locally on individual players. The skin definition is in a file 'skin.txt'. For the local user skin, it goes in folder skins/skin. I plan to let the user select the skin folder so they can switch skins easily. For for the station skin which gets uploaded over the network it goes in metadata/skin.
Look at the example skin.txt for the format. Basically it is a list of files and optional colour modifiers for them. The filename and colour modifier string must be seperated by an & and no spaces.

There is one optional file 'logo=' which is a top area logo, and is intended for use by the 'whole network' skin. It will work, but is replaced by the station logo, so won't show up if the station logo gets there first. 'logo_text_colour' etc don't get used if there is no logo file defined. The network skin is not implemented yet.

There are also a couple of text colours defined, using the #rrggbb method that web page colours use. 'buttons_text' is an 0/1 flag and controls whether the default button symbols are drawn. Disable if you define a proper buttons_icons.bmp file. 'buttons_text_colour' defines the colour of the default symbols.

'buttons_bevels' is a flag, for the bevel edge around the buttons, disable if your buttons don't need it.

The image sizes needed are:
Frame: Not sure actually, and it tiles so the edges must match up or you will see the join.

Background: Not sure, and it also tiles. This is the background for the station list area. Use a colour modifier to help with the visibility of text drawn on it. 

Buttons: 569(new size) x 21 pix (minimum), a long thin strip. Buttons are all in a row as they appear on the player. The bottom row is first on the left, followed by the 5 top buttons. Main buttons are 32x20, slider is 100x20, top buttons are 32x18. List scrollbar buttons are 20x18. The volume slider 'thing' (what is is called?) is 13x16, and is only cut from the 'up' buttons strip.

The list scrollbar is a tall thin image. Minimum size of image is 20 wide, and any height, but very short will make it take longer to render. Top and bottom of the slider should tile so that you don't see the join.

There is also an optional bitmap that overlays the buttons. It must be a bmp, not a jpg/gif. Black is used as transparent. The idea is this bitmap has masked symbols for the buttons which overlay the main buttons image. You could of course use an image editor to put these images into the main buttons jpg/gif directly. This method just makes it simpler if you have one set of button symbols that you overlay on different changeable 'ordinary' textures. This bitmap can have a colour modifier string.

There is a file buttons_icons_with_outlines.bmp, this shows the button positions, which are the same on the buttons image strips. Note that the 'up' buttons are cut one pixel below the 'down' ones, this is so the texture moves visibly down by one pixel when the button is depressed. This is also why the strips need to be 21 pixels high when the buttons are only 20 pixels high.


Embedded website
----------------

There is an embedded website for each stream. Like the old 'view' but better with multiple pages.
Make a folder 'web' in your broadcast streamer folder, put in it a html file index.html. This is your website root page. You may include .jpg .gif & .png images, and link to other htm/html pages. All includes and links/anchors must be relative, 'http://' or 'file://' are not allowed. They must also be in the web folder, '../' is also not allowed yet. Max number of files is 200, and max file size is currently 200k. Css should work embedded in each html page, it may or may not work as included css files. It's supposed to.
Site is not polled for changes, you have to use the rescan button or stop/start the broadcast to force it to update.

Users will see the view button if your stream has an embedded website. The entire website has to download before it can be displayed so don't make it too big. The actual site files are downloaded by the new background p2p file transfer process, the one that downloads the station logos. Files are cached locally, and are stored between sessions, so the whole thing doesn't re-download each time. 

There is an example skin and web site in the beta rar.

Note: external links must be to just a url www.blahblah.com not www.blahblah.com/index.html, because of crap coding.

Video
-----

WMV and NSV are supported. NSV requires the user has winamp or VLC installed. Find NSV instructions on our website...

WMV:
You have to relay the stream from the encoder rather than have the encoder push the stream to the bropadcaster, I don't know the push connection protocol for WMV. Set the 'send request for asf stream' checkbox. This is neccesary because there appears to be a defacto standard happening in all the examples I looked at, where the client must pretend to the server to be a particular 'NSPlayer' player application.
VLC for example will ask three times for the stream, twice as itself, and then as 'NSPlayer' and with a different format request. If I answer either of the first two requests, VLC will try and play the stream as mpeg data, and will throw errors. If I answer the third request with exactly the same data, VLC knows it's asf data and parses it correctly.
(I found out what is actually happening here, the player is requesting info about the stream, and the stream header, before actually requesting the stream.)

Playback is by internal or external player, default is internal. For external, Streamer drops and runs a 'sound.wmv' file, which should automatically invoke Windoze Media Player. You can also drag and drop sound.wmv onto another player.
This 'wmv' file is actually an 'asx' redirector file, not actual stream data. I am doing this rather than using the asx file type because on most people's PC's .asx simply isn't registered to any player, but wmv is, and VLC/WMP etc are smart enough to tell it's actually an asx file.

H264 may be supported in the future, but there are fees payable for using it so maybe not.
Theora will be supported sometime, but if there is the same bother with headers that Ogg had then maybe not soon.

The video playback is in a seperate window. Embedding the video in the streamer app was just really user unfriendly and annoying.



Tuning links
------------

The beta has a new URI type:  'streamerp2pbeta://' It will stay this way until 1.47 is phased out. I intend for v2.00 and 1.47 to co-exist for a while. 2.00 needs more testing than it gets as a 'beta beta' so it is being unleashed on the public as a real version, but 1.47 is still staying around for a bit because 2.00 is a lot different.




Colour Modifier Strings
-----------------------

These change the displayed colours of an image, and are intended to make changing colours simpler than using a graphics program. They contain the following, in either decimal or hex numbers (but don't mix decimal and hex in a string).

# 1st 3 numbers: Red Green and Blue scales (contrast).
0 is zero, 256/0x100 is full (1.0). (note its 256/0x100 not 255/0xff). Can be greater than 256/0x100 to exagerate saturation, and can also be negative to invert colours. If you do use a negative you will have to add some bias or you will just get black.

# 2nd 3 numbers: Red Green and Blue bias. These are the 'brightness' for each colour. 0 is none, 256 is full. Bias is just added to the colour. Can be >256 or negative.

After saturation+bias is done, the colour is converted into YUV format. Y is the 'black and white' component, U and V are combined colour phase+saturation values which work together as a 2D number. The YUV value is modified by the next 4 numbers.

# Yscale, Ybias.
These are the same as the RGB ones, except they work on the black&white Y value

# UVsaturation
This is like the colour control on a TV. Turn the colour saturation up or down. 256/0x100 is normal colour. Can be >256.

# UVphase was supposed to shift the colours around the spectrum, but it doesn't quite do what I expected because I misunderstood how YUV works. U and V are really 'red difference' and 'blue difference' signals, and they can be 'rotated' to give different colour remapping, but that does not give a simple 'shift up the spectrum'. I'll change it when I work out how. 0x400/1024 is max phase shift, and brings the colours all the way around to where they started.

# FlipGB and Processing order
These last 2 are 0/1 flags, FlipGB just swaps Green and Blue at the input stage, to reverse the spectrum.
Processing order is intended to choose if the RGB scale/bias is done before or after the colour phase shift, but since UV phase shift is 'broken-ish' it is notimplemented yet.

So the string is this:
Redscale,Greenscale,Bluescale, Redbias,Greenbias,Bluebias, Yscale,Yybias, UVsaturation,UVphase, FlipGB,Processorder.

The example string in logo.txt does nothing at all to the colours.


Congestion control
------------------

Version 2.00 Z has a new congestion control. It backs off the speed of individual feeds that have a packet loss over a critical value, and also drops feeds and reduces overall upload allocation for loss over all feeds. It uses average loss over all feeds, rather than using the lowest loss seen on any feed, which is more logical. This is because the per-feed loss calculation tends to be very noisy.



Iain McLeod. 25/03/2011.